You would reference the snapshot dependency by the timestamped snapshot. > This makes it a reproducible build. > > > How confident are we that the repository will not alter or delete them? >
They cannot be altered. I see artefacts there that are more than a decade old. But we cannot rely on their permanence. Putting the SHA into the jar's manifest is easy. And this blog post shows how you can also expose this info on the command line: https://medium.com/liveramp-engineering/identifying-maven-snapshot-artifacts-by-git-revision-15b860d6228b Given there's no guaranteed permanence to the snapshots, we would need to have the git sha in the version, so if much older versions can't be downloaded it can still be rebuilt. This is done like: <revision>1.0.0_${sha1}-SNAPSHOT</revision> > linking in the source code into in-tree is a significant thing to do > > > Could you explain why? I thought your preferred alternative was merging > the source trees permanently > Linking or merging while it is still also being a separate library and repo. If we are really not that interested in it as a separate library, and dev change is high, or the code is somewhere less accessible, then in tree makes sense IMHO.
