desruisseaux commented on PR #508: URL: https://github.com/apache/maven-jar-plugin/pull/508#issuecomment-5339574577
@hboutemy, @elharo: about the issue of adding the missing directories while preserving deterministic file order, a workaround may be to add in the pull request a post-generation step where the JAR file is read and rewritten with entries added using `java.util.zip`. That step would be executed only when files were enumerated (as opposed to specifying the directory to the `jar` tool). I will try to do that during the weekend. I will also check for the other issue raised by @seregamorph (too many `target` directories created). Above proposal should preserve strict reproducible builds in the JAR plugin. For longer term, I still believe that bit-for-bit reproducible builds is too much and that we need _semantically_ reproducible builds, but this is another story for maybe a separated plugin. Thanks @laeubi for the link to Tycho. artifact comparator. Thanks @jaikiran for stepping in. The issue is that for creating a reproducible build with the `jar` tool, we need to enumerate explicitly all the `*.class` files and resources in order to enforce an order that does not depend on the file system. But the problems with enumerating files are: * We have to repeat the `-C` option for every file (not a blocking issue). * When specifying `foo/bar/X.class`, the `jar` tool does not generate `foo/` and `foo/bar/` entries. It does if we specify the whole directory, but then the entry order is back to unspecified even if we are still enumerating the files in addition to the directories. While the absence of directory entries is legal according @pzygielo (thanks for the tip), it seems to be an issue with Spring. A possible `jar` tool evolution could be to specify a new option in replacement of `-C`. It could be, for example, `--change-dir`. The new option would behave in the same way as `-C` with two differences: * All files after `--change-dir` would be relative to the specified directory instead of only the first file. * Adding `foo/bar/X.class` implies adding `foo/` and `foo/bar/`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
