Digest algorithm and Maven snapshots

[myron0815]

It seems to not break functionality; only irritating / wrong metadata
TL;DR

The Resource.computeDigest() Line 241 ignores the META-INF.
This might work well for most users, but i encountered an issue while working with my project:

Have a Maven project, distributing sometimes some snapshot jars (for testers).
In gui, i display the JAR manifest impl version, to get a clue what is deployed in what version.

When i now release that jar, so that ONLY the metadata changes (but not a class file; compared to last snapshot update), the digest is the same, and never downloaded/updated the release version! (still displaying snapshot in gui)
(Would be the same, if you always release unchanged jars, to have them all on same version)

What is/was the need for skipping the meta-inf?
How could i change that w/o breaking live instances (aka GD self update)?
It gives me a slightly bad feeling, that not the jar i deploy is downloaded and checked 1:1...

[samskivert]

That code was written 12 years ago, so the memory is hardly clear in my mind, but I think there were some issues with what was in META-INF making JarDiff do the wrong thing.

It should be possible to add a flag saying "include everything in the diget" but that would have to be passed both to Getdown and to the Digester, which seems error prone. Maybe we could include a marker file inside META-INF that tells Getdown to include the contents of META-INF in the digest. Then no flag coordination would be needed, computeDigest() would just see the file in Digester and later in Getdown and could do the right thing.

I'm afraid I don't have time to put that together right now though. So busy!

[myron0815]

Thanks for your response.
Will think about it... (and if i can live with that)
Thanks!

Wow... that old.
Still great little product :)

[borgogelli]

That's a very big problem for us.
Yesterday we updated the pom.xml file of our application in order to connect some new libraries and we noticed that our users were unable to update to the new relese because any change in the MANIFEST file are not detected by the digest algorithm.
We thought that getdown was using some standard cheksum algorithm like sha1 or md5.
What's the matter with these hash function ?

Thank you for that great project (one of the most underrated)

Regards

Andrea

[beirtipol]

Aha! That explains what just happened:)

[beirtipol]

FYI, have removed this in my fork and all seems to work well. Any chance it can be merged in?

[borgogelli]

OFFTOPIC: On the other side, sometimes we have the same code, compiled twice, which has a different hash. How does the digest algorithm work ? Can someone post a link to the source ?

[samskivert]

https://github.com/threerings/getdown/blob/master/src/main/java/com/threerings/getdown/tools/Digester.java

[samskivert]

Oops, here's the thing that actually hashes a particular file:

https://github.com/threerings/getdown/blob/master/src/main/java/com/threerings/getdown/data/Digest.java

[samskivert]

Oops oops, here's the really real thing that computes a digest of one file, the above stuff does the whole app:

https://github.com/threerings/getdown/blob/master/src/main/java/com/threerings/getdown/data/Resource.java#L206

[samskivert]

FWIW we resolved this by making the new version of the digester algorithm (digest2.txt) include the contents of META-INF files.