Packaged jars are not the same in different *:packageBin configs

[stevedlawrence]

Expected behaviour

$ sbt package
$ md5sum target/scala-*/*.jar
$ sbt universal:packageBin
$ md5sum target/scala-*/*.jar
$ sbt rpm:packageBin
$ md5sum target/scala-*/*.jar

It looks like each time *:packageBin is called the jars are repackaged even though nothing changes. This causes the hashes to be different due to things like timestamps in the jar metadata, even though the actual content of the jars are the same. Ideally, the jars would not be rebuilt and would be exactly the same regardless of how they're packaged. If they were all the same, it would be easier for someone to verify that the various packages all have the exact same content and there wasn't some mixup during a release process.

Note that if you run two different package commands in the same config, then it does not seem to repackage on the second command and the jars do have the same hash as expected, for example.

$ sbt universal:packageBin
$ md5sum target/scala-*/*.jar
$ sbt universal:packageZipTarball
$ md5sum target/scala-*/*.jar

The hashes are the same

Actual behaviour

The md5sums are different. Usually the only difference is the creation timestamp in jar metadata. The actual contents inside the jar are the same.

Information

• What sbt-native-packager are you using: 1.3.4
• What sbt version: 1.0.4
• What is your build system (e.g. Ubuntu, MacOS, Windows, Debian ): Fedora 27
• What package are you building (e.g. docker, rpm, ...): zip & rpm
• What version has your build tool (find out with e.g. rpm --version): 4.14.1
• What is your target system (e.g. Ubuntu 16.04, CentOS 7): Fedora 27

[muuki88]

Thanks for your detailed issue 🤩 and sorry for the late reply.

I assume the main reason for this is how sbt caching works. My experience in this field is rather limited, but from that and your description it looks like that caching seems to be bound to the executed scope.

The contents are generated from the mappings setting.

• mappings in (Compile, packageBin) contain the application jar content
• mappings in Universal contain the contents of zip, tarGz, etc. IIRC these are also scoped to the task. So it's actually mappings in (Universal, packageBin), mappings in (Universal, packageTgz)
• for deb and RPM contain everything in universal. This is done by adding the content to linuxPackageMappings in Debian or Rpm.

It seems that the caching information somehow gets lost in these content hierarchies.

[stevedlawrence]

This issue appears to have been resolved by upgrading SBT to 1.2.1 and sbt-native-packager to 1.3.6. I haven't done testing to determine whether this was a bug in SBT or in this plugin, or when it was fixed, but this combo of versions resolves it.

[muuki88]

There hasn't been any change in native-packager, so the kudos goes to the SBT team 👍🤗