> Linking or merging while it is still also being a separate library and repo.
I am still unclear why you think this is “a significant thing”? > On 18 Jan 2023, at 10:41, Mick Semb Wever <m...@apache.org> wrote: > > > > >>> 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. >
