Hi Danny, Thank you for writing a patch! It looks good to me. We will need to apply this to the core-updates branch, right? I think that changes to the ant-build-system will cause all packages that use it to be rebuilt. Danny Milosavljevic writes: > +(define* (generate-jar-indices #:key outputs #:allow-other-keys) > + "Generate file \"META-INF/INDEX.LIST\". This file does not use word wraps > +and is preferred over \"META-INF/MAINFEST.MF\", which does use word wraps, > +by Java when resolving dependencies. So we make sure to create it so that > +grafting works." Is that the only reason? My understanding is that we want to generate the JAR indices not only (1) to ensure that grafting will work properly, but also (2) to ensure that the reference scanner will find all the store paths produced in the output JAR. Goal (2) is important because if a store path is used at run-time by the installed software, but the path is treated as "dead" by the garbage collector, then the path may be removed during garbage collection, which would break the software. If you agree, then could you update the docstring with a little more info? > + (define (generate-index jar) > + (invoke "jar" "-i" jar)) > + (every (match-lambda > + ((output . directory) > + (every generate-index (find-files directory "\\.jar$")))) > + outputs)) Does the jar program find the classes here via the CLASSPATH environment variable, which was set earlier during the configure phase by the generate-classpath procedure? -- Chris