On 2017-04-19, Matt Benson wrote: > I had forgotten about this. When testing my other changes I noted that no > InputStream was returned here, due to the requested entry name including > the leading slash from the jar resource URL; the jar entries encountered > during testing, at least, lacked the leading slash.
So this has never worked and nobody has noticed so far, strange. > Due to this the actual reading of the resource was deferred to the XML > parser. Skipping the slash fixed this issue for me and seemed > anecdotally to decrease the amount of time needed to run the > tests. Wouldn't we end up with a null InputStream and an exception being thrown later on? > You of course know much more about the file format than I; I have been > unable to find a definitive resource that confirms that jar file > entries should always lack a leading separator. A leading slash would violate the ZIP spec https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT 4.4.17.1 The name of the file, with optional relative path. The path stored MUST not contain a drive or device letter, or a leading slash. ... so the current code is certainly wrong. I'll try to dig deeper into this the coming days unless anybody else beats me to it. Many thanks Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
